What starts this process, where it ends, who acts and on which surfaces. Scheduling spans three apps: RiverSync proposes (Admin), the customer chooses (Portal), the servicing partner works the visits it services within scope (Partners).
Top to bottom in sequence; lanes are the actors. Node shape follows the master conventions — pills start and end the process, grey nodes are backbone events, diamonds are decisions. The decline branch loops back to a fresh proposal.
Each row is one node on the swimlane: who acts, what happens, the domain event it emits, and the requirement or rule it traces to.
Every id, event, service and entity this process touches — each linked to the document that owns it. This is how you hop from a step back to the requirement, the service or the data model behind it.
The WF-rules that bind this workflow — the master holds the full set; the DM-rules (ERD) and SVC-rules (Domain) they extend stay with those documents. Note WF-7: the partner read defers to the single partner-scope resolver (SVC-6), and WF-5: RiverSync proposing into a customer tenant is audited into both trails.
| Version | Date | Changes |
|---|---|---|
| 0.1 | 29 Jun 2026 | First draft — service scheduling joins the operations group as the propose → select negotiation across Portal · Admin · Partners. New requirements PTL-11 · ADM-7 · PAR-15; new entities VisitProposal · VisitProposalOption · SchedulingPreference (DM-57…59); Field owns scheduling (SVC-20); events visit.proposed · visit.proposal-accepted · visit.proposal-declined. |